Commitment transaction

funding tx を unlock する

channel open 時には funding tx と最初の commitment tx(refund tx とも呼ぶ) が作られる

6種類の lock の方法がある

to_local(P2WPKH)

unlock 条件

to_self_delay

revoc key, remote_sig

to_remote(P2WPKH)

remote sig

anchor tx 2種類

HTLC output

二種類ある

Offered(outgoing) HTLC output

自分から送金する HTLC

unlock 条件

revoc key, remote sig

preimage, remote sig

HTLC-timeout tx

timeout 時は自分に帰ってくる。自分宛の tx を自分が持つ場合は timelock が必要

HTLC の expire 時間を指定するので絶対時間での timelock が必要

Received(incoming) HTLC output

受け取る HTLC

unlock 条件

revoc key, remote sig

HTLC-success tx

正常時に自分に送金される。自分宛の tx を自分が持つ場合は timelock が必要

timeout 時

CLTV で timelock

HTLC-Timeout and HTLC-Success Transactions

These HTLC transactions are almost identical, except the HTLC-timeout transaction is timelocked.

HTLC-timeout tx は input になる HTLC tx の script で CLTV による timelock がかけられる

Offerd HTLC tx か Received HTLC tx を input にする

署名

success tx: マルチシグ, preimage

timeout tx: マルチシグ

unlock 条件

revoc key, remote sig

CSV timelock, local sig

timeout する場合の説明

HTLC output を直接 remote node や自身の鍵で unlock するのではなく、 HTLC-success tx, HTLC-timeout tx で unlock する２段階方式を採用している

The reason for the separate transaction stage for HTLC outputs is so that HTLCs can timeout or be fulfilled even though they are within the to_self_delay delay. Otherwise, the required minimum timeout on HTLCs is lengthened by this delay, causing longer timeouts for HTLCs traversing the network.

あまりよくわかっていない、、、

これが分かりやすい

local への支払いは常に to_self 分の delay が必要で、timeout した HTLC を取り戻す場合にも to_self delay が必要。

そうでなければ、HTLC output は CLTV 後はいつでも使える状態になり、仮に HTLC が fullfied であったとしても、すぐに取り返すことができてしまう

なので、to_local の HTLC は CLTV による HTLC の expire 時間の設定に加えて、to_self delay が必要

つまり、HTLC は CLTV により expire しているのにも関わらず、それを自分に取り戻す場合はそれ以上に時間がかかることを意味する。つまり実質的な CLTV は CLTV + CSV。

CLTV で expire した後も to_salf delay の間は、送金相手が preimage を使って受け取りができてしまう。expire 後なのに。

もし CTLV delta がこの実質的な CLTV よりも小さい場合(delta < CLTV)、資金を失う可能性があるので、CLTV delta を 実質の CLTV よりも大きくする必要がある。

delta > CSV でないといけない？

なぜ資金を失う可能性があるか

Received HTLC は Offerd HTLC よりも早く expire してはいけない

Received HTLC の CLTV > Offerd HTLC の CLTV でないといけない

Received が先に expire すると、その資金は相手に戻る。でも自分の Offerd はまだ expire していないので、送金相手に送金される。自分は送ったのに、その分は受け取れない状況になっている

実質的な CLTV が CLTV + CSV である場合、CLTV delta は当然 CSV も含めて考える必要がある

delta が 5 block、Received CLTV が 105 block とすると、Offerd CLTV は 100 block。CSV は 10 block とする。

この時、Offerd の HTLC を回収するには minimum block 110 まで待つ必要がある(expire が block 100 で、プラス CSV 10 block 分)

received は 105 + 10 block で 115 block

問題なくない？

問題があるとすれば、receive を取り返せる前に、offerd が timeout するのでそちらの取り返し作業も始まってしまってレースになる？

しかしこの場合、次の Hop もこの timeout 時間の影響を受けることになる???

commitment tx の to_local には to_self_delay 分の timelock をかける。to_self_delay は割と長いので HTLCの timeout はこれよりも短い時間に設定できないと、ルーティングで資金がロックされる時間が長くなってしまう？

多段にする理由

There is still a problem: Making the output to Alice encumbered by both these timelocks could in the worst case extend the HTLC’s timeout by to_self_delay. In other words, Bob could have an extra to_self_delay blocks in order to sweep the hash-locked output even though the HTLC is technically expired.

From here, one can imagine a scenario where we have an HTLC that can be timed out (absolute block height passed), but we can't spend it (timing it out) until our CSV period has also expired. Therefore, one needs to set their CSV values taking into account the absolute timelock (CLTV) value as well. Critically, before a user can cancel their incoming off-chain HTLC (timing out the outgoing on-chain), they need to wait for this CSV period. However, if the CSV is greater than the time lock delta (diff between incoming and outgoing HTLCs), they've created a race and could possibly lose money.

一段の問題点

CLTV で expire していても、CSV を待っている間に preimage を使って送金を完了させることができてしまう

もちろん完了されてしまったら、自分も preimage を使って受け取ればよいのだが、そのためには自分の CSV を待つ間は、offerd HTLC の CLTV はまだ expire していない必要がある。となると CLTV の値は非常に大きくなってしまう。これが上で説明されていること。

２段にすると

CLTV expire した時点で、HTLC output は HTLC timeout tx で消費できるので、preimage を使って送金を完了することはできない。ゆっくり CSV を待てば良い。

to self delay CSV はチャネルごとに決まっている